Los sistemas integrados de administración financiera SIAF (página 2)

Poner en marcha un nuevo modelo de gestión puede requerir una redefinición del papel de ciertas unidades administrativas y organismos públicos. Además, necesita una estrategia de desarrollo de recur- sos humanos, preferentemente basada en un servicio civil y una gerencia pública profesionalizados, com- prometidos con el proceso de cambio y bien remunerados. Estos requisitos contribuyen tanto al éxito de los cambios como a su sostenibilidad.

En síntesis, la experiencia internacional demuestra que los SIAF deben diseñarse e implementarse en el contexto de procesos de reforma más amplios. Además de una adecuada preparación y una clara definición de la secuencia de las acciones y de la provisión de los recursos financieros, humanos y tecno- lógicos necesarios, se debe contar con los siguientes requisitos básicos: i) una definición clara y explíci- ta del marco conceptual y metodológico que se adoptará en el proceso; ii) sensibilización y capacitación masiva para los diferentes estratos políticos, directivos y técnicos de la burocracia pública involucrados;

iii) un apoyo político firme, explícito y permanente del más alto nivel al proceso de cambio, que garan- tice la transparencia y la difusión en todo el proceso; iv) resultados rápidos, confiables y sostenibles, que

Gráfico 3.4: requerimientos para la implantación de un siaf

fuente: compilación de los autores.

permitan preservar el apoyo político necesario. En el gráfico 3.4 se ejemplifica una secuencia bajo estos requerimientos estratégicos.

Los siaf y su tecnología

Los avances tecnológicos han puesto a disposición del sector público una gran diversidad de recursos técnicos para el diseño y la implementación de SIAF, como las tecnologías de arquitectura de hardware y software que se han venido utilizando en ALC.

Arquitecturas tecnológicas

Arquitectura de programación monolítica

En una arquitectura de programación monolítica, el software aplicativo no está distribuido ni a nivel físi- co ni lógico sino que reside y se ejecuta en computadores centrales (mainframes). Los usuarios disponen de terminales para acceder a los datos y su acceso a las bases de datos generalmente se hace en línea. En este esquema las bases de datos se hallan totalmente centralizadas. Un ejemplo de esta arquitectura lo constituye el SIAF de Brasil.

Esta arquitectura fue ampliamente utilizada en los años setenta y ochenta. Actualmente las grandes empresas (como las corporaciones bancarias) siguen utilizando este tipo de tecnología por practicidad (es decir, los aplicativos son ligeros y por tanto rápidos de ejecutar), por seguridad y por la especialización del

3 En esta sección se consideran únicamente los aspectos tecnológicos que se han venido utilizando en SIAF de la administración del gobierno central, y en ningún caso de la administración regional o municipal, ni de empresas privadas.

software propietario para determinados tipos de negocios. Hoy en día, en vez de terminales brutas para ac- ceder a las bases de datos centrales se utilizan microcomputadoras personales con un software emulador de terminales. En este modelo la calidad de la conectividad condiciona fuertemente el desempeño del sistema.

Arquitectura de programación cliente-servidor

En la arquitectura de programación cliente-servidor el software de los aplicativos se distribuye física y ló- gicamente en distintos equipos, que pueden ser servidores de mediano porte (centrales y/o distribuidos) o las computadoras personales de los usuarios. Los usuarios disponen de computadoras personales para acceder a los datos y las bases de datos pueden estar distribuidas en distintos servidores o centralizadas. Un ejemplo de esta arquitectura es el SIAF de Uruguay (SIIF). Los usuarios acceden a bases de datos centralizadas en el ministerio de Finanzas en tiempo real a través de líneas de teleproceso. Además, en cada institución existen servidores cuyo software aplicativo se actualiza diariamente desde los computa- dores centrales, y los usuarios locales acceden desde sus computadoras personales a estos servidores institucionales a través de redes.

La tecnología cliente-servidor fue muy utilizada en los años noventa, pero hoy en día se considera desactualizada. Excepto en pocos casos, la mayoría los SIAF de la región que la utilizaron vienen abando- nando esta plataforma y migrando sus sistemas a la tecnología multicapas.

Arquitectura de programación multicapas

En la arquitectura de programación multicapas se separa la lógica de la programación de los negocios (lógica del negocio) de la del diseño físico (lógica del diseño). Generalmente existen tres capas separadas:

i) la capa de presentación, que se usa para presentar en la computadora del usuario las pantallas para en- trar o consultar información (esta capa se comunica únicamente con la capa del negocio); ii) la capa del negocio, donde residen los distintos aplicativos que constituyen el negocio y sus reglas de funcionamien- to (esta capa se comunica con la capa de presentación para recibir peticiones y entregar resultados, y con la capa de datos para solicitar al gestor de las bases de datos que entregue o almacene información), y

iii) la capa de datos, donde se administran la grabación de los datos y los requerimientos de información (esta capa se comunica únicamente con la capa del negocio).

La arquitectura de programación multicapas se diseminó en los últimos 10 años y hoy se emplea en la mayoría de los SIAF de la región. Entre los países que utilizan esta arquitectura se encuentran Argenti- na, Guatemala, Honduras, Nicaragua y Paraguay.

Arquitectura SOA (Service-Oriented Architecture)

La arquitectura orientada al servicio (SOA) se ha venido desarrollando durante más de dos décadas. Se basa en considerar al negocio total de la organización como un compuesto de diversos servicios de menor

complejidad, asimilables a procesos o negocios. Estos servicios individuales son más fáciles de desarrollar y mantener informáticamente, llevando a la larga a menores costos de operación y mantenimiento. Ade- más, dentro de esta arquitectura se hace abstracción de la tecnología sobre la cual están construidos los distintos negocios, por lo cual los sistemas antiguos (legados) pueden seguir trabajando dentro de la SOA.

La clave para la armonización de los distintos componentes dentro de la SOA son las interfaces que se establecen entre ellos bajo estándares universales (XML, WEB). Estas interfaces permiten a la vez la in- teroperabilidad y la flexibilidad que se precisan para los cambios de software en los distintos servicios. La SOA es altamente compatible con lenguajes de programación Java y metodologías de diseño y desarro- llo de sistemas orientados a procesos como la BPM (Business Process Management).

La arquitectura SOA y la metodología BPM fortalecen al usuario final del sistema, que pasa a mane- jar directamente el diseño de flujos y de reglas del negocio, con lo cual se reduce su dependencia de las áreas de tecnología cuando es necesario efectuar modificaciones en el sistema.

En la región los SIAF de Bolivia (módulos de la nueva versión del SIGMA en plataforma Web), Chile (SI- GFE) y Perú (inicialmente el componente de formulación presupuestaria) están siendo desarrollados bajo la arquitectura SOA y el uso de metodología BPM.

Arquitectura de bases de datos centralizadas y distribuidas

En la arquitectura de bases de datos centralizadas, las bases de datos de los SIAF residen en equipos cen- trales que generalmente se encuentran ubicados en los ministerios de Hacienda. Los usuarios acceden a estas bases de datos desde sus terminales o computadoras personales en tiempo real a través de líneas de comunicaciones (redes dedicadas, conmutadas o Internet). La mayoría de los SIAF de la región traba- ja sobre bases de datos centralizadas.

La arquitectura de bases de datos distribuidas consiste en la interconexión de diferentes bases de datos ubicadas en distintas instituciones, e interconectadas a través de líneas de comunicación para la validación y el intercambio de información en línea. Esta tecnología exige una alta disponibilidad de lí- neas de comunicación que interconectan los sistemas y los servidores, y no se han detectado experien- cias de este tipo en la región.

Sin embargo, existen experiencias con bases de datos distribuidas sin interconexión en línea. Un ejemplo es el SIAF de Perú, que en una arquitectura cliente-servidor mantiene servidores y bases de da- tos distribuidas en las entidades, a las cuales acceden los usuarios desde sus computadores a través de redes. El software reside en los computadores de los usuarios y en los servidores institucionales. Las insti- tuciones actualizan una base de datos central en el ministerio de Economía y Finanzas por medio de pro- cesos por lotes en diferido asimétrico.

Esta arquitectura genera el riesgo de crear inconsistencias, ya que la información de las institucio- nes no se valida en línea contra las bases datos centrales. Además, el sistema de seguridad se torna débil

porque en el nivel central no se pueden identificar exactamente los usuarios que realizan transacciones en las entidades. Por otra parte, esta arquitectura resulta costosa, ya que las instituciones deben disponer de personal técnico para hacer el mantenimiento a los aplicativos y operar los sistemas, así como también contar con hardware y software operativos de apreciable capacidad (servidores).4

Estrategias y tendencias

En general los SIAF de la región han evolucionado junto a las arquitecturas tecnológicas. En los años ochenta y noventa casi la totalidad de los SIAF de la región se implementaron utilizando arquitecturas monolíticas o de cliente-servidor. Recién hacia finales de la década de 1990 se inició la implementación de SIAF con arquitectura multicapas. La puesta en marcha de SIAF multicapas utilizando redes de comu- nicación Web se iniciaron desde el comienzo de la década de 2000.

¿Hacer o comprar hecho?

Al margen de la arquitectura utilizada, en los años ochenta y noventa casi todos los SIAF de la región se implementaron por medio de un desarrollo propio (dentro de la organización). Recién a finales de la dé- cada de 1990 se comenzó a contratar firmas para la generación de los sistemas, aun cuando estos desa- rrollos se siguen haciendo a medida y no con la adquisición de software comercial.

La alternativa de llevar adelante un diseño propio básicamente opera con dos modalidades de con- tratación: i) contratación individual de personal conceptual experto en SIAF y de personal informático, y

• ii) contratación de firmas consultoras, que a su vez subcontratan el personal conceptual experto en SIAF y el personal informático.

La primera alternativa se ha utilizado en Argentina, Bolivia, Brasil (con una empresa pública), Ecuador, El Salvador, Guatemala, Honduras, Nicaragua, Paraguay y Uruguay.5 Si bien esta alternativa tiene la venta– ja potencial de acarrear menores costos, puede generar problemas relacionados con la contratación y el mantenimiento de una gran cantidad de personal técnico, además de producir una enorme inercia insti- tucional, lo que en muchos casos alarga los plazos de implementación.

La alternativa de contratar firmas ha sido utilizada en Chile, Colombia y recientemente en Perú, país este último que ha contratado el desarrollo de la formulación presupuestaria con una empresa privada. Si bien esta alternativa puede involucrar costos más elevados en el corto plazo, reduce la dependencia del gobierno hacia grandes grupos de personal técnico, y puede ser más barato en el largo plazo.

4 Estas características del SIAF en Perú se refieren al sistema que estaba en operación a principios de 2011. Para 2012–13 se tiene previsto lanzar un nuevo sistema que solucionaría todos estos problemas.

5 Ecuador adaptó recientemente un SIAF que le proveyó Guatemala.

Soluciones integrales de gestión

Además de las alternativas mencionadas, existen soluciones integrales de gestión financiera que se ofre- cen en el mercado y que pueden adaptarse a las entidades públicas. Se trata del ERP, que se ha disemi- nado en las empresas privadas desde los años noventa. Este ha sido adaptado para el sector público y se ofrece en el mercado de proveedores de sistemas informáticos con la denominación GRP.6

Los ERP son sistemas integrales de gestión para una organización. Están compuestos por módulos que ofrecen diferentes funcionalidades, como producción, ventas, compras, logística, contabilidad (de varios tipos), gestión de proyectos, sistemas de información geográfica (GIS), inventarios y control de al- macenes, pedidos, nóminas, etc. Los ERP se caracterizan por combinar diferentes funciones administrati- vas integradas en una única aplicación.

A diferencia de otros sistemas de software empresarial, los ERP son sistemas integrales, escalables, modulares y adaptables. Aunque existen variedades de ERP en el mercado, incluido el GRP, en ALC sólo Costa Rica ha adoptado esta tecnología como solución de SIAF con un sistema SAP.7

En algunos países de la Organización para la Cooperación y el Desarrollo Económicos (OCDE), como Alemania o España, se operan sistemas GRP que integran la máxima cantidad de funciones administra- tivas posible y uniforman el flujo de información de las organizaciones, ya sea incorporando diferentes módulos a un mismo sistema, o estableciendo requisitos técnicos que garanticen la interoperabilidad en- tre distintos sistemas.

Más recientemente, Francia ha implementado un SIAF de tipo GRP (Proyecto Chorus/SAP), pero a un costo que resulta muy alto para los estándares latinoamericanos, ya que involucró una inversión de alre- dedor de €500 millones, de los cuales €30 millones se pagaron en licencias, €150 millones se utilizaron para adaptar el sistema, €120 millones se invirtieron en hardware y €200 millones se destinaron a capaci- tación y gestión del cambio.8

Propiedad del código fuente

Otra cuestión a definir en la implementación de un SIAF es la propiedad del código fuente. Un soft- ware de código cerrado o no libre recibe el nombre de "propietario". La redistribución o modificación de este tipo de software está prohibida. Por consiguiente, el software propietario genera dependencia del comprador al proveedor. El software propietario tiene costos de licenciamiento y por lo general está

6 Las principales motivaciones para la adopción de un ERP en el sector público son integrar la información e incrementar la eficiencia de los procesos (Raymond, Uwizeyemungu y Bergeron, 2005).

7 En Guyana se usa el sistema desarrollado por la empresa FreeBalance con características de ERP, pero este no cubre todas las funciones de una gestión integrada de recursos, y se concentra mayormente en el presupuesto y la contabilidad.

8 Los montos son aproximados y se presentan solamente como una referencia general de los costos involucrados.

bien terminado, se ofrece en el mercado y compite en calidad y precio con otras soluciones de software similares.

Por otro lado, el software libre (o abierto u open source) permite modificar los programas fuente para cualquier propósito y redistribuir copias para otros usuarios potenciales. En función del tipo de licencia- miento otorgado puede eventualmente tener un costo, pero en general no lo tiene o este es muy bajo. Sólo se deben pagar el soporte y el mantenimiento para obtener un producto que funcione bien y per- manezca actualizado, y ocasionalmente se debe pagar por la distribución del producto.

Desde finales de los años noventa se ha venido incrementando el uso de software abierto en las en- tidades públicas de la región en países como Argentina, Brasil, Chile, Ecuador, República Dominicana y Venezuela. Esto se debió principalmente a que las universidades comenzaron a trabajar con este tipo de software (lo que permitió conocerlo y divulgarlo), a que su precio era atractivo, y a que aparecieron en el mercado empresas que suministraban soporte.

En lo que concierne a los componentes del SIAF o a sistemas auxiliares en particular, existen varias experiencias de uso de software libre en la región, como la formulación presupuestaria de la administra- ción central en Argentina y Brasil; y el sistema impositivo de Colombia (sistema MUISCA: http://www.dian. gov.co/content/muisca/muisca.htm).

En general, se puede afirmar que el software abierto es mucho más barato que el propietario, y que las entidades que lo adoptan logran ahorros significativos. A manera de ejemplo, sólo en 2008 el gobier- no federal de Brasil estima que ahorró alrededor de R$ 30 millones (cerca de US$18 millones) mediante el uso de software libre (IDG NOW, 2008).

Habitualmente, una vez que las entidades públicas de la administración central han adquirido un software propietario que se considera estratégico, es difícil que cambien de modalidad, a menos que la solución estratégica vaya a renovarse en su totalidad o haya cumplido su vida útil. Pero también hay adopciones de software mixtas, como los entornos de desarrollo (sistemas operativos y servidores de aplicaciones con software libre pero bases de datos propietarias).9 Cabe anotar que los proveedores tam- bién están fabricando soluciones mixtas, que se construyen con base en un software libre (por ejemplo Java), pero concluyen en un producto propietario que tiene costos de licenciamiento.

La definición del tipo de software que debe adquirir una entidad pública deberá basarse en los es- tudios técnicos, en las evaluaciones de la oferta de estas herramientas en el mercado de cada país y del personal que las conoce (como en el caso de Brasil, donde esto está muy desarrollado), y en las políticas informáticas de las instituciones. Sin embargo, es notable que mientras hace poco más de 10 años en ALC

9 Tal solución está siendo utilizada en el desarrollo del nuevo SIGMA-Web del gobierno central de Bolivia, lo cual deberá exten- derse a los gobiernos subnacionales.

no se encontraba ningún aplicativo importante construido bajo la tecnología de software libre, a la fecha existen emprendimientos de envergadura.

recuadro 3.1: iniciativas recientes de uso de software libre en Alc

el ministerio de economía (mecon) de argentina está desarrollando su nueva versión del si- dif en plataforma Web como un sistema de código abierto, arquitectura multicapas y base de datos centralizada. el nuevo sidif ya funciona en plataforma Web con un proceso de implanta- ción gradual que empezó en 2005 y prevé el reemplazo y la operación plena de todas las anti- guas funcionalidades. los módulos de formulación y modificaciones presupuestarias ya están desarrollados. el mecon ha optado por un desarrollo interno, con el apoyo técnico de expertos tercerizados. el objetivo es que el sidif-Web apoye la implementación de un modelo de ges- tión por resultados en el gobierno central, con base en la descentralización operativa y en la vinculación entre las asignaciones financieras y el logro de metas de los programas guberna- mentales.

por su parte, en 2010 el ministerio de planificación, presupuesto y Gestión (mpoG) de Brasil puso en operación un sistema de código abierto para la formulación del presupuesto anual y del plan plurianual del gobierno federal. el sistema integrado de orçamento e planejamento (siop) fue desarrollado internamente con el apoyo técnico de la universidad de brasília. el gobierno fe- deral decidió adoptar un software libre, lo que permitió ahorros tanto en términos de costos como de tiempo, gracias a la eliminación de complejos procesos licitatorios. el objetivo es que se con- tinúe perfeccionando el siop para apoyar las necesidades de las áreas sectoriales del gobierno, aumentar la transparencia y ofrecer nuevas funcionalidades al proceso de planificación federal.

Posiblemente en el mediano y largo plazo la utilización mixta de software abierto y propietario será una tendencia que combine las ventajas de ambos: los bajos costos, las posibilidades de adecuación de los programas fuente y las facilidades técnicas que brinda el primero, junto con la madurez, la estabili- dad, la velocidad de ejecución, las garantías de funcionamiento y el soporte técnico propios del segundo.

Un panorama de la región

En 2009–10 el BID realizó una encuesta en 13 países de la región para conocer el estado de las tecnolo- gías informáticas utilizadas por los gobiernos en sus respectivos SIAF. El cuadro 3.2 muestra un resumen de los aspectos tecnológicos de la información relevada.

cuadro 3.2: uso de tecnología en los siaf de alc

fuente: recopilación de los autores.

Por un siaf de calidad

Un análisis de la sección de funcionalidades de la encuesta del BID antes mencionada (Solarte, 2010) iden- tificó a los SIAF de Argentina y Brasil como los más avanzados en ALC, seguidos por los de Bolivia, Chile, Guatemala, Honduras y Paraguay, que se hallan en un nivel intermedio (no necesariamente en este or- den). Con un nivel inferior de madurez se identificaron los SIAF de Costa Rica, Nicaragua, Perú, Repúbli- ca Dominicana y Uruguay.

Sin embargo, un buen SIAF no es garantía de una buena administración financiera en un sentido más amplio. Para evaluar la administración financiera pública de un país se puede recurrir a las evaluaciones

del Programa de Gasto Público y Rendición de Cuentas (PEFA, por sus siglas en inglés) (véase www. pefa.org). En general administradas por agencias multilaterales o donantes internacionales, su objetivo es orientar acciones de reformas que mejoren la capacidad institucional para la gestión fiscal en los países evaluados (incluidas las áreas de gasto público, compras y contrataciones, y sistemas financieros), e incre- menten la transparencia y la rendición de cuentas.

En ALC existen 12 PEFA validados por los países evaluados y con resultados publicados (cuadro 3.3).

Muchos otros se encuentran en proceso de preparación o discusión.

Si se evalúan de forma agregada estos resultados,10 se pueden identificar tres grupos de países: i) un primer grupo que abarca a los países más avanzados en la administración financiera pública (Brasil, Co- lombia, El Salvador y Perú); ii) un grupo intermedio (Bolivia, Honduras, Paraguay y Trinidad y Tobago), y

• iii) un grupo que tiene los puntajes más bajos (Belice, Haití, Jamaica y República Dominicana). Aunque en muchos casos este análisis de la administración financiera está en línea con el estudio de los SIAF realiza- do por Solarte (2010) (por ejemplo, para Bolivia, Brasil, Honduras, Paraguay y República Dominicana), no siempre es este el caso.

Muchos de los indicadores del PEFA que miden la calidad de la administración financiera pública en un gobierno nacional o subnacional pueden usarse para medir la eficacia de las funcionalidades de un SIAF. Sin embargo, para medir la eficiencia y otras características, se necesitan otros indicadores (recua- dro 3.2).

La disponibilidad y el análisis de indicadores PEFA, complementado con indicadores específicos de SIAF, son importantes tanto para el diseño de un nuevo SIAF como para el seguimiento y la evaluación de su implantación y operación.

10 Si se suma de la cantidad de buenas calificaciones (A o B+) por país o la correlación de puntos por tipo de calificación (A=4; B+=3,5; B=3; C+=2,5 y así sucesivamente) se llega a un mismo resultado.

cuadro 3.3: resultados de las evaluaciones de pefa en alc

sistemas integrados de administración financiera para la gestión pública moderna | 101

cuadro 3.3: resultados de las evaluaciones de pefa en alc

(continuación)

recuadro 3.2: ejemplos de indicadores para evaluar siAf

cobertura de entidades: porcentaje del total de entidades de la administración central con sis- tema propio de ejecución presupuestaria y financiera sin interfaces automáticas con el siAf.

cobertura de presupuesto: porcentaje del presupuesto administrado por las entidades de la administración central que tienen sistema propio.

acceso en tiempo real: porcentaje de las unidades ejecutoras de la administración central que operan en el siAf en tiempo real.

Pagos: monto de los pagos que son emitidos por el siAf, ya sea manualmente o electrónicamente (excluidos los pagos de nómina individuales a cada funcionario, y considerando que los giros glo- bales a las entidades se toman como un solo pago), dividido por el total de pagos gubernamentales.

Pagos electrónicos: monto de los pagos que son emitidos por el siAf electrónicamente direc- to a proveedores y contratistas, dividido por el total de pagos de las entidades de la administra- ción central.

cuT: total de cuentas bancarias que existen en la administración central fuera del siAf.

conciliación bancaria: total de cuentas que se concilian en tesorería electrónicamente, dividi- do por el total cuentas bancarias de la administración central.

contabilidad automática: el sistema permite obtener automáticamente los asientos contables.

alineamiento de clasificadores: clasificadores presupuestarios, contables (plan de cuentas) y catálogos de compras.

interoperabilidad: cantidad de interfaces electrónicas con otros sistemas (compras, recursos hu- manos, bienes, inversión, gestión de proyectos, recaudación, proyecciones macroeconómicas, etc.).

cantidad de usuarios: número total de usuarios registrados activos (o cantidad de claves de ac- ceso).

cantidad de transacciones: número promedio mensual de transacciones en el siAf.

costos: costos de desarrollo, implantación, operación y mantenimiento.

Fuente: compilación de los autores.

Conclusiones, tendencias y desafíos

El modelo SIAF como un sistema único de administración financiera pública, incluida la operación de una CUT, sigue siendo una tendencia predominante en ALC.

Si bien este modelo surgió como respuesta a las crisis fiscales de los años ochenta y noventa, conti- núa la tendencia de seguir adoptándolo, porque además de permitir consolidar la estabilidad macroeco- nómica y la responsabilidad fiscal, ayuda a promover la mejora en los procesos decisorios, la transparencia y la modernización de la gestión pública.

Sin embargo hay discusiones todavía incompletas sobre el nivel de integración más adecuado para cada país en cuanto a las funcionalidades básicas de un SIAF (presupuesto, tesorería, contabilidad y deu- da pública). En lo general, cuanta más integración haya, mayor será la seguridad del control sobre el gas– to público, y mejores serán también la calidad de la información y la eficiencia de los procesos de trabajo. Por otro lado, los costos de una integración y una automatización totales son muy altos, tanto para la im- plementación del sistema como para su operación y mantenimiento.

La evolución de los SIAF en ALC se ha visto afectada por cambios de orientación en la administra- ción pública, que ha virado desde un enfoque que enfatizaba solamente la legalidad y los controles for- males hacia un enfoque gerencial que mira las necesidades de información para el apoyo de la toma de decisiones. Estos cambios implicaron un mayor uso de nuevos instrumentos de gestión y la incorpora- ción de nuevas tecnologías de la información.

La integración o interoperabilidad de los SIAF de la región con otros sistemas administrativos todavía es pequeña. Existe un reconocimiento claro del potencial para avanzar hacia una mejor instrumentación de los procesos de toma de decisiones a partir de la información gerencial generada por la integración de los SIAF con otros sistemas administrativos gubernamentales; sin embargo, si bien hubo avances con el área de compras y contrataciones y con sistemas de pago de personal, en los demás sistemas administrati- vos la integración es muy escasa. Ha habido muchos intentos por mejorarla, y se puede identificar una ten- dencia hacia una mayor interoperabilidad, pero todavía persisten obstáculos institucionales que exceden los aspectos tecnológicos y los costos de implantación. Los tradicionales incentivos políticos y burocráti- cos a la fragmentación institucional se reflejan en las resistencias y dificultades para una mayor integración. Los requerimientos estratégicos para el establecimiento o la renovación de un SIAF no abarcan sola- mente aspectos tecnológicos y de gestión de proyectos. En general, se logra más efectividad en el con- texto de reformas más amplias, con una clara definición de la secuencia de las acciones y de la provisión de los recursos financieros, humanos y tecnológicos necesarios. Además, se debe llevar a cabo la sensi- bilización y capacitación masiva de los diferentes estratos políticos, directivos y técnicos de la burocra- cia pública involucrados, y contar con apoyo político durante todo el proceso de cambio, garantizando la transparencia y la difusión de información en todo el ciclo del proyecto.

En cuanto a los aspectos tecnológicos, varios países de ALC vienen actualizando sus versiones de SIAF para migrar a tecnologías informáticas más actualizadas de software, hardware y redes, campo en el que se destacan principalmente aquellas basadas en una arquitectura Web. La mayoría de los SIAF de la región fue o está siendo desarrollado internamente, con o sin el apoyo de empresas de desa- rrollo de sistemas. En el caso de que esta operación se realice exclusivamente con consultores indivi- duales o funcionarios públicos, si bien en el corto plazo los costos suelen de ser menores, en el largo plazo pueden incrementarse debido a la inercia institucional que se genera. Por otro lado, la contrata- ción de firmas consultoras para el desarrollo de módulos específicos tiende a aumentar la integralidad del sistema, con un responsable general por todos los productos, y una visión más externa y comple- ta de los procesos.

Esta situación podría cambiar en los próximos años, gracias al interés de algunas empresas de soft- ware por desarrollar sistemas específicos para el sector público. Sin embargo, todavía es difícil que un sis- tema comercial atienda todas las necesidades funcionales específicas de un país, lo que conduce a que los países mezclen las alternativas de "desarrollo propio" con el uso de "opciones ofrecidas en el merca- do", de forma a cubrir todas las funciones de gestión financiera pública requeridas.

No existen soluciones únicas que puedan aplicarse sin un análisis profundo del contexto y de los costos involucrados. El debate entre las opciones de "desarrollo propio de soluciones" o internas (con o sin el apoyo de firmas consultoras) frente a la "adquisición de sistemas" disponibles en el mercado (siste- mas libres para la venta) debería siempre guiarse por análisis técnicos de tipo costo-beneficio. Por otra parte, los ERP o GRP a la venta en el mercado aparecen cada vez más como una alternativa, principalmen- te para casos de menor escala como, por ejemplo, el nivel subnacional.

Respecto de las opciones tecnológicas para el desarrollo informático, actualmente se puede iden- tificar una tendencia hacia el uso de BPM y SOA; sin embargo, las herramientas disponibles en el merca- do que generan las líneas de programación a partir del diseño de los procedimientos financieros que se quiere informatizar, suelen resultar útiles pero no son suficientes para el diseño completo de un nuevo SIAF, y necesitan complementarse con el uso de otras herramientas de desarrollo.

Estas herramientas son atractivas debido a que los "dueños" de los procesos pueden revisar sus pro- cedimientos antes de informatizarlos, y en el largo plazo tener más propiedad o participación sobre even- tuales ajustes futuros, con una menor dependencia de las áreas de informática. Por otra parte, el software libre es una novedad que probablemente será considerada cada vez más en los próximos años, y podrá constituirse en una opción con un nivel de seguridad razonable a un costo mucho menor.

Todavía es importante avanzar en el desarrollo y la aplicación de indicadores para el análisis y el mo- nitoreo de la calidad de los SIAF y de la administración financiera pública en general. Actualmente los análisis existentes se basan en evaluaciones PEFA complementadas con variables específicas de SIAF. La capacidad de los gobiernos para atender las crecientes demandas de información por parte de la sociedad debe constituirse en un parámetro adicional a ser considerado en las evaluaciones de sus siste- mas de administración pública en los próximos años.

En general, a pesar de esta evolución positiva, persiste el desafío de avanzar hacia sistemas más vol- cados a la gestión y al apoyo de la toma de decisiones. Para lograrlo, sería necesario relacionar la ejecu- ción financiera con la planificación y el monitoreo de la ejecución física de los programas y proyectos, por medio de indicadores y metas. Además, los registros administrativos del SIAF deberían apoyar un mode- lo de gestión por resultados con información confiable y oportuna. Por otra parte, todavía sigue en pie el desafío de establecer una gestión de costos basada en el uso de la información generada por los SIAF y en la utilización de planes de cuentas diseñados para uso gerencial.

Por lo tanto, los SIAF no deben ser vistos solamente como herramientas informáticas, sino que pue- den cumplir un rol estratégico más amplio en la modernización de la gestión pública. Hay evidencia de cómo la generación y oferta de información confiable y oportuna a gestores gubernamentales y ciuda- danos puede catalizar reformas y generar capital político para sustentarlas. Actualmente, las modernas herramientas de inteligencia de negocios pueden facilitar este trabajo y potenciar sus efectos. No obs- tante, los procesos de identificar, organizar y suministrar información no pueden ser vistos como desafíos exclusivamente técnicos, pues exigen liderazgo político y construcción de consensos para que se garan- tice su sostenibilidad.

Bibliografía

Allen, R., S. Schiavo-Campo y T. Columkill. 2004. Assessing and Reforming Public Financial Management. A New Approach. Washington, D.C.: Banco Mundial.

Brusa, J. 1996. Gerencia financiera pública. Washington, D.C.: BID.

Dener, C., J. A. Watkins y W. L. Dorotinsky. 2011. Financial Management Information Systems: 25 Years of World Bank Experience on What Works and What Doesn"t. Washington, D.C.: Banco Mundial.

Diamond, J. y P. Khemani. 2005. "Introducing Financial Management Information Systems in Developing Countries". Documento de trabajo del FMI, pp. 1–33, Washington, D.C.: FMI.

Figueroa, R. 2001. "Los avances y potencialidades de los sistemas integrados de administración financie- ra del sector público". Documento presentado en la 4ª sesión del XIV Seminario Regional de Políti- ca Fiscal, Santiago, Chile.

Hashim A. y B. Allan. 1999. "Information Systems for Government Fiscal Management". Sector Studies Se- ries. Washington, D.C.: Banco Mundial.

IDG NOW. 2008. Software livre gera economia de R$ 30 milhões para governo federal. Disponible en: http://idgnow.uol.com.br/computacao_corporativa/2008/12/09/software-livre-gera-economia-de- r-30-milhoes-para-governo-federal/.

Khan, A. y M. Pessoa. 2009. "A Critical Element of a Government Financial Management Information Sys- tem Project". Notas y manuales técnicos del FMI. Washington, D.C.: FMI.

Pattanayak, S. e I. Fainboim. 2010. "Treasury Single Account: Concept, Design, and Implementation Issues".

Documento de trabajo WP/10/143. Washington, D.C.: FMI.

Peterson, S. 2006. "Automating Public Financial Management in Developing Countries". Documento de trabajo No. RWP06–043. Cambridge, Mass.: John F. Kennedy School of Government, Harvard Univer- sity.

Raymond, L., S. Uwizeyemungu y F. Bergeron. 2005. "ERP Adoption for eGovernement: An Analysis of Mo- tivations. Proceedings of the eGovernment Workshop 2005 (eGOV05)". Londres: Brunel University.

Solarte, S. 2010. Análisis de madurez de los SIAF. Informe de consultoría IFD. Documento inédito. Wash- ington, D.C.: BID.

Autor:

Percy Reategui Picon